Properly use createOneInstanceComponentFactory for javaloader

After 424a7f404565e068995e2a9827d5bc6f76920ec8 "add some more libs to libmerged"
had added javaloader to libmerged, destruction of static xStaticRef started to
cause problems at least during CppunitTest_services of --enable-mergedlib
Windows builds (presumably because the relative order of static variable
destruction had changed).

Change-Id: I8307570222cc9a3d9511d090d0dae7f7dfe7a9ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90254
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
diff --git a/stoc/source/javaloader/javaloader.cxx b/stoc/source/javaloader/javaloader.cxx
index 065ff12..d6f77cd 100644
--- a/stoc/source/javaloader/javaloader.cxx
+++ b/stoc/source/javaloader/javaloader.cxx
@@ -336,21 +336,13 @@
/// @throws Exception
static css::uno::Reference<XInterface> JavaComponentLoader_CreateInstance(const css::uno::Reference<XComponentContext> & xCtx)
{
    css::uno::Reference<XInterface> xRet;

    try {
        MutexGuard guard( getInitMutex() );
        // The javaloader is never destroyed and there can be only one!
        // Note that the first context wins...
        static css::uno::Reference< XInterface > xStaticRef = *new JavaComponentLoader(xCtx);
        xRet = xStaticRef;
        return *new JavaComponentLoader(xCtx);
    }
    catch(const RuntimeException &) {
        TOOLS_INFO_EXCEPTION("stoc", "could not init javaloader");
        throw;
    }

    return xRet;
}

} //end namespace
@@ -362,7 +354,7 @@
{
    {
        JavaComponentLoader_CreateInstance, loader_getImplementationName,
        loader_getSupportedServiceNames, createSingleComponentFactory,
        loader_getSupportedServiceNames, createOneInstanceComponentFactory,
        nullptr , 0
    },
    { nullptr, nullptr, nullptr, nullptr, nullptr, 0 }